1. Field of the Invention
The present invention relates to electronic commerce. Particularly, the invention relates to purchasing goods using electronic money. Specifically, this invention brings the highest degree of atomicity to the proposed standard for electronic commerce, the Secure Electronic Transactions standard.
2. Description of Related Art
Electronic commerce includes sending electronic payments over a public network to obtain electronic goods or promises of the delivery of physical goods. Important standards have been proposed in a draft for public comment, Secure Electronic Transactions, 67 page Book 1 and 269 page Book 2, by VISA.RTM. and MasterCard.RTM., Feb. 23, 1996, incorporated herein by reference. Crucial questions in such purchases are: What can customers, merchants, and banks lose on the Internet? Whom must they trust? And who takes the risks?
Answers to these questions vary across the multitude of proposed protocols for electronic commerce on the Internet. However, an examination of a broad range of these protocols makes clear that in electronic commerce, customers can lose their money if transactions are not both reliable and secure. Reliability requires atomicity in the Newtonian sense: transactions must fail completely or succeed completely. The traditional technique for achieving atomicity is rollback, where steps are reversed until the most recent consistent state is reached. For example, if a customer's attempt to transfer funds from checking to savings fails, funds withdrawn from the customer's checking account are placed back into the customer's checking account. If money cannot be returned in an aborted transaction, then it is destroyed, lost, stolen, or duplicated. Transactions in which money is destroyed, lost, stolen, or duplicated are not reliable.
Before I describe my invention more completely, a consideration of two fundamental questions is in order: Why are liable transactions important? And, what are the properties of a reliable electronic commerce protocol? To answer these questions, I must first address a more basic issue: What is money? Defined by its three elemental functions, money is a store of value, a standard of value, and a medium of exchange. Ensuring that electronic commerce maintains money's functions as store and standard of value is not difficult. In contrast, ensuring that electronic commerce maintains money's function as a medium of exchange is difficult. Money as a medium of exchange requires reliability in transactions, and providing transactional reliability in electronic commerce is not trivial.
Money as a medium of exchange requires special transactional properties. As a medium of exchange, money must have transactional durability; that is, money must be conserved in transactions, not created or destroyed. Money transactions must be consistent; the amount received by the seller must be the same amount paid by the buyer, with no change in that amount occurring during the transaction.
The transactional properties that enable money to serve as a medium of exchange amount to transational reliability. And therein lies the answer to my initial question: why are reliable transactions important? Reliable transactions in electronic commerce are important because they are necessary to the proper functioning of electronic money as a medium of exchange.
There remains, then, the second question: what are the properties of a reliable electronic commerce protocol? The study of distributed data bases has defined the characteristics of reliable data bases transactions as atomicity, consistency, isolation and durability. These are known as the ACID properties.
Physical transfers of money illustrate the ACID properties of a reliable transaction. ACID properties are innate in exchanges of physical money. Please note that during this, and all future analyses, I take advantage of gender--specific language to simplify my discussion. The customer is assumed female; the merchant male; and the bank neuter. This allows me to use she, he and it without worrying that the reader may confuse the noun referenced by the pronoun.
Consider a customer's handing a dollar bill directly to a merchant. This transaction maintains atomicity: The dollar bill will not be lost as it leaves the customer's hand and is transferred to the merchant. There is always exactly one dollar; it is never duplicated or destroyed. If the dollar is dropped, then the customer can pick it up and return the transaction to its previous state. This simple physical safeguards does not necessarily hold in an electronic transaction.
In electronic commerce, payment message must travel over an open network, that is not secure, from the customer to the merchant. Without verifiable acknowledgment in the protocol, the customer will not know that the merchant received the payment message. Under the widely used transmission control protocol (rCP), a payment may be duplicated when the communications protocol believes the packet containing the payment message may be destroyed by network failure. If a payment message is lost, delayed, or destroyed, confusion rather than consistency may result.
In sum, transactional reliability is not a trivial matter in electronic commerce. Thus, the provision of highly reliable transactions is a critical research issue in the analysis of electronic commerce protocols, and one I undertake in this invention.
There are three classes of atomicity: money atomicity, goods atomicity and certified delivery.
Of course, electronic transactions may have no atomicity. No atomicity requires mutual trust among participants. The physical equivalent is sending cash or goods in the mail to a post office box. Customer or merchant fraud can be simple in systems with no atomicity.
Electronic transactions may have money atomicity. The physical equivalent is paying cash. In money-atomic systems there is no mechanism for certification of merchandise delivery. If used for remote purchase with accepted techniques for the delivery of physical goods, money atomicity is quite adequate. But fraud, through a customer's theft of goods or a merchant's refusal to deliver goods after payment, can be trivial when systems with only money atomicity are used for goods with on-line delivery, such as software. Secure Electronic Transactions has money atomicity (MasterCard, 1996).
Electronic transactions may have money atomicity. Goods atomicity is the equivalent of Collect on Delivery. The merchant is not paid unless there is a delivery. The customer does not pay unless there is a delivery.
Finally, electronic commerce systems may provide certified delivery. With certified delivery the customer only pays if the item delivered matches the description of the item promised. The merchant is only paid if the item delivered matches the description previously agreed upon by the merchant and customer. Certified delivery applies only to information goods--however a receipt, invoice or purchase order are all special cases of information goods.
In this invention we extend SET to include certified delivery.
In this disclosure, hash functions are functions that given the output it is difficult to determine the input. With a hash function information is mathematically transformed so that it can be used for verification but not read. That is to say, with a hash function, information can be verified without being known. The output of a hash function is typically much smaller than the input.
Hashing is distinct from secret key or symmetric encryption. With secret key encryption a single key encrypts and decrypts information. Without the key nothing can be known or verified; with the key the encrypted information can be decrypted, read, and verified as having not been tampered with during transmission. DES is a known encryption technique that encrypts data according to a key, and triple DES is a three times application of the DES algorithm that uses three keys in succession.
Public key encryption is a technique where two keys are generated: a public key and a private key. Data encrypted under the private key can only be decrypted with the public key, and vice versa. Usually, the private key is kept secret by a party, and the public key is published to all by a trusted source. A party receiving private key encrypted data may obtain the corresponding public key from the trusted source, and then decrypt the data.
Signing, related to encryption, is any known technique by which data is digitally signed so that it can be trusted to have come from the party signing the data. For example, a signing party may encrypt data under its private key. Any person decrypting the data under the corresponding public key will know the identity of the signing party to the confidence that the trusted source has verified the identity of the public key owner. Any person who decrypts the data can also be certain that it has not been altered by any but the owner of the corresponding private key.